Installation

Cargo

First you need to install the crate by adding this entry to your Cargo.toml dependencies list:

bevy_mod_scripting = { version = "0.9.0", features = ["lua54"]}

Choose the language features you wish enabled and add them to the features block.

Bevy Plugin

The next step is to add the BMS plugin to your application.

app.add_plugins(BMSPlugin);

You can modify each of the plugins contained within the plugin group using set(MySubPlugin).

Language Features

Each language supported by BMS can be switched-on via feature flag as below:

Extra Features

In order to fit as many use cases as possible, BMS allows you to disable a lot of its functionality.

By default all of the useful features are enabled, but you may disable them if you wish if you are only needing BMS for script lifecycle management, and want to populate the bindings yourself.

Managing Scripts

Scripts live in the standard Bevy assets directory. Loading a script means obtaining its byte representation and associated language.

Evaluating a script means:

• parsing the script body,
• and creating or updating the resources which store script state.

Loading

Scripts can be loaded into memory via the AssetServer.

let handle = asset_server.load::<ScriptAsset>("my_script.lua");

Or scripts can be created in memory.

let mut script = ScriptAsset::from("x = 0".into());
script.language = Language::Lua;
let handle = script_assets.add(script);

This will not evaluate any code yet.

Evaluating

A script does not participate in any callbacks until it is evaluated, to evaluate a script you must first attach it to an entity, or to a static script entry.

To evaluate a script, add it to a ScriptComponent or to StaticScripts.

Load File via AssetServer

#![allow(unused)]
fn main() {
extern crate bevy;
extern crate bevy_mod_scripting;
use bevy::prelude::*;
use bevy_mod_scripting::prelude::*;

fn load_script(asset_server: Res<AssetServer>, mut commands: Commands) {
    let handle = asset_server.load::<ScriptAsset>("my_script.lua");
    commands.spawn(ScriptComponent(vec![handle]));
}
}

Create ScriptAsset and Add It

#![allow(unused)]
fn main() {
extern crate bevy;
extern crate bevy_mod_scripting;
use bevy::{asset::Assets, prelude::*};
use bevy_mod_scripting::prelude::*;

fn add_script(mut script_assets: ResMut<Assets<ScriptAsset>>, mut commands: Commands) {
    let content: String = "x = 0".into();
    let mut script = ScriptAsset::from(content);
    script.language = Language::Lua;
    let handle = script_assets.add(script);
    commands.spawn(ScriptComponent(vec![handle]));
}
}

Unloading

When you no longer need a script asset you can freely unload it, but the script attachment will persist. In order to trigger the on_script_unloaded etc. callbacks, you need to remove the script from the ScriptComponent or StaticScripts.

When that happens a corresponding ScriptEvent::Detached will be dispatched, and then handled by a DeleteScript command. Once the last script in a context is removed, the context itself will also be removed.

Hot-loading scripts

To enable hot-loading of assets, you need to enable the necessary Bevy features as normal see the bevy cheatbook for instructions.

Assuming that hot-reloading is enabled for your app, any changes to script assets will automatically be picked up and the scripts re-loaded.

File Extensions

Normally the set of supported extensions is pre-decided by each language plugin.

I.e. Lua supports ".lua" extensions and Rhai supports ".rhai" extensions.

Scripts are mapped to the corresponding language plugin based on these and so it is important to use them correctly.

If you would like to add more extensions, you need to populate them via app.add_supported_script_extensions.

    app.add_supported_script_extensions(&[".pua"], Language::Lua);

Advanced

Normally not necessary but knowing these exist could be useful for more advanced use cases.

Manually (re)loading scripts

In order to manually re-load or load a script you can issue the CreateOrUpdateScript command:

use bevy::prelude::*;
use bevy_mod_scripting::prelude::*;
let create_or_update = CreateOrUpdateScript::<LuaScriptingPlugin>::new(script_handle)
    .with_content("print(\"hello world from new script body\")");
commands.queue(create_or_update);

replace LuaScriptingPlugin with the scripting plugin you are using.

Manually Deleting scripts

In order to delete a previously loaded script, you will need to issue a DeleteScript command like so:

commands.queue(DeleteScript::<LuaScriptingPlugin>::new(script_handle));

Replace LuaScriptingPlugin with the scripting plugin you are using.

Loading/Unloading timeframe

Script asset changes are processed together with bevy asset systems, in the Last schedule. These are converted to ScriptEvent's which are handled right after via the ScriptingSystemSet::ScriptingCommandDispatch system set.

Attaching Scripts

Once you have scripts discovered and loaded, you'll want to run them.

At the moment BMS supports three methods of making scripts runnable:

• Attaching them to entities via ScriptComponent's
• Adding static scripts
• Creating dynamic systems ⚗️ (see the script systems section)

And then sending script event's which trigger callbacks on the scripts.

Attaching scripts to entities

In order to attach a script and make it runnable simply add a ScriptComponent to an entity

    commands.entity(my_entity).insert(ScriptComponent::new(vec![my_script_handle, another_script_handle]));

When this script is run the entity global will represent the entity the script is attached to. This allows you to interact with the entity in your script easilly.

Making static scripts runnable

Some scripts do not require attaching to an entity. You can run these scripts by loading them first as you would with any other script, then either adding them at app level via add_static_script or by issuing a AddStaticScript command like so:

    commands.queue(AddStaticScript::new(my_script_handle));

The script will then be run as any other script but without being attached to any entity. and as such the entity global will always represent an invalid entity.

Note: Internally these scripts are attached to a dummy entity and as such you can think of them as being attached to an entity with an id of 0.

Running Scripts

Scripts can run logic either when loaded or when triggered by an event. For example the script:

print("hello from load time")
function on_event(arg1)
    print("hello from event time")
    print(arg1)
end

Will print "hello from load time" when the script is loaded, and "hello from event time" when the script receives an event targeting the on_event callback with a receiver list including this script or entity.

In order to trigger on_event you need to first define a label, then send an event containing the label:

#[derive(Reflect)]
pub struct MyReflectType;

// define the label, you can define as many as you like here
callback_labels!(OnEvent => "on_event");

// trigger the event
fn send_event(mut writer: EventWriter<ScriptCallbackEvent>, mut allocator: ResMut<AppReflectAllocator>) {

    let allocator = allocator.write();
    let my_reflect_payload = ReflectReference::new_allocated(MyReflectType, &mut allocator);

    writer.send(ScriptCallbackEvent::new_for_all_scripts(
        OnEvent,
        vec![my_reflect_payload.into()],
    ));
}

Note the second argument is the payload we are sending with the event, in this case we are sending an arbitrary reflect type MyReflectType. This can be any type you like, as long as it implements Reflect.

Other variants of the ScriptValue enum are available for sending different types of data, such as ScriptValue::Integer for primtive, types.

Event Handlers

In order for the events you send to actually be picked up, you need to inject special systems into your application. These systems will listen for the events and trigger the appropriate callbacks on the scripts:

app.add_systems(Update, event_handler::<OnEvent, LuaScriptingPlugin>);

Note the system is parameterized by the label we defined earlier, and the scripting plugin we are using. You can add as many of these systems as you like.

The event handler will catch all events with the label OnEvent and trigger the on_event callback on all targeted scripts which have that callback defined.

In order to handle events in the same frame and not accidentally have events "spill over" into the next frame, you should make sure to order any systems which produce these events before the event handler systems.

Commands

You can also use manually issued RunScriptCallback commands to trigger script callbacks as well. These must be run from a exclusive system, or via a any other system but with limited access to the world (See the WithWorldGuard system param, which will allow you to create a WorldGuard and use it to run the commands)

Controlling Script Bindings

In this book we refer to anything accessible by a script, which allows it to communicate with your Rust code a binding (which in previous versions was more generically referred to as a script API).

The "binding" here being used as in: binding script code to rust code.

Namespaces

Namespaces are a way to group functions together, and are used to prevent naming conflicts. You can have multiple namespaces, and each namespace can have multiple functions.

Language implementations will also look for specific functions registered on your type first before looking at the generic ReflectReference namespace.

Dynamic Functions

Everything callable by scripts must first be registered in the dynamic function registry. Notably we do not make use of the normal bevy function registry to improve performance and usability. This means you cannot call just any function.

In order for a function to be callable by a script it must adhere to a few requirements:

• Each argument must implement FromScript.
• Each return type must implement IntoScript.
• Each argument must also implement GetTypeDependencies
• Each return type must also implement GetTypeDependencies

The into/from requirements allow us to convert these types to ScriptValue's, and each supported scripting language can then marshall these into the script.

Note these types are implemented for primitives, but if you want to interact with one of your Reflect implementing types, you will need to use one of Ref<T>, Mut<T> or Val<T> wrappers in place of &T, &mut T and T respectively.

These wrappers enable us to safely interact with bevy, and claim any necessary mutex'es on Resources, Components or Allocations.

The GetTypeDependencies, trait is simply a local trait alias for GetTypeRegistration with less strict type requirements. It allows us to register all the types necessary for the function calls, so that you don't have to register anything manually. If your type implements GetTypeRegistration you should not face any issues on this front.

Registering Script Functions

Registering functions can be done via the NamespaceBuilder like below:

    NamespaceBuilder::<ReflectReference>::new(&mut world)
        .register(
            "hello_world",
            |s: String| {
                println!(s)
            },
        );

    NamespaceBuilder::<GlobalNamespace>::new_unregistered(&mut world)
        .register(
            "hello_world2",
            |s: String| {
                println!(s)
            },
        );

This will allow you to call this function within lua like so:

some_type:hello_world("hi from method!");
hello_world2("hi from global!");

Note the new_unregistered call instead of new, this is because GlobalNamespace is not a Reflect type, and the new call also automatically registers the type in the reflection registry.

Macros

The above is a bit tedious, so instead you can use the script_bindings macro, which applies to impl blocks like so:

#[script_bindings(name = "test_fn")]
impl TestStruct {
    /// My docs !!
    /// 
    /// Arguments:
    /// * `_self` - the first argument
    /// * `arg1` - the second argument
    /// Returns:
    /// * `return` - nothing
    fn test_fn(_self: Ref<TestStruct>, mut arg1: usize) {}
}


pub fn main() {
    let mut app = App::new();
    register_test_fn(app.world_mut())
}

Note the documentation will automatically be picked up and stored for the purposes of reflection and documentation generation, including argument/return type specific docs.

Context Arguments

Each script function call always receives an additional context argument: FunctionCallContext. You can opt-in to receive this argument in your own function definitions by adding it as the first argument.

The context contains requests from the caller to your function, such as "I am calling you from a 1-indexed array system, please convert the index first", This argument is only relevant if you're targeting multiple languages.

It also allows you to retrieve the world via FunctionCallContext::world().

You can use this as follows:

    NamespaceBuilder::<ReflectReference>::new(&mut world)
        .register(
            "hello_world",
            |ctx: FunctionCallContext, s: String| {
                let world = ctx.world()?;
                let should_use_0_indexing = ctx.convert_to_0_indexed;
                println!(should_use_0_indexing);
                println!(s)
                Ok(())
            },
        );

Generic Arguments

Sometimes you might want to be generic over the type of argument you're accepting, you can do so by accepting ScriptValue arguments like so:

    NamespaceBuilder::<ReflectReference>::new(&mut world)
        .register(
            "is_integer",
            |s: ScriptValue| {
                match s {
                    ScriptValue::Integer(i) => true,
                    _ => false
                }
            },
        );

You can treat return values similarly.

Fallible functions

Your script functions can return errors either by:

• Returning Result<T: IntoScript, InteropError>
• Returning ScriptValue and manually creating the ScriptValue::Error(into_interop_erorr.into()) variant.

Reserved Functions

There are a few reserved functions that you can override by registering them on a specific type:

In this context overridable indicates whether language implementations will look for a specific function on your type before looking at the generic ReflectReference namespace. You can still remove the existing registration for these functions on the ReflectReference namespace if you want to replace them with your own implementation.

Note the ReflectReference namespace is special, in that functions defined on it, act like a fallback and hence apply to ALL references.

Globals

By default, each type registered with the type registry, has the following set:

• a static reference in the global namespace, i.e.: Vec3, Mat3
• an entry in the types global type cache, i.e.: types.Vec3, types.Mat3

You can filter the types included by customising the CoreScriptGlobalsPlugin

Modifying Script Contexts

You should be able to achieve what you need by registering script functions in most cases. However sometimes you might want to override the way contexts are loaded, or how the runtime is initialized.

This is possible using Context Initializers and Context Pre Handling Initializers as well as Runtime Initializers.

It is however always reccomened to use the dynamic script function registry whenever possible, as it is more flexible and easier to use. It also allows you to introspect available functions easier.

Context Initializers

For example, let's say you want to set a dynamic amount of globals in your script, depending on some setting in your app.

You could do this by customizing the scripting plugin:

let plugin = LuaScriptingPlugin::default().add_context_initializer(|_context_key: &ContextKey, context: &mut Lua| {
    let globals = context.globals();
    for i in 0..10 {
        globals.set(i, i);
    }
    Ok(())
});

app.add_plugins(plugin)

The above will run every time the script is loaded or re-loaded and before it handles any callbacks.

Context Pre Handling Initializers

If you want to customize your context before every time it's about to handle events (and when it's loaded + reloaded), you can use Context Pre Handling Initializers:

#![allow(unused)]
fn main() {
use bevy::prelude::*;
use bevy_mod_scripting::prelude::*;
fn scripting_plugin(app: &mut App) {
    app.add_plugins(LuaScriptingPlugin::default()
                       .add_context_pre_handling_initializer(|context_key: &ContextKey, entity: Entity, context: &mut Lua| {
        let globals = context.globals();
        if let Some(script_id) = context_key.script_id.as_ref() {
            globals.set("script_name", script_id.to_owned());
        }
        Ok(())
    }));
}
}

Runtime Initializers

Some scripting languages, have the concept of a runtime. This is a global object which is shared between all contexts. You can customize this object using Runtime Initializers:

#![allow(unused)]
fn main() {
use bevy::prelude::*;
use bevy_mod_scripting::prelude::*;
fn scripting_plugin(app: &mut App) {
    app.add_plugin(SomeScriptingPlugin::default().add_runtime_initializer(|runtime: &mut Runtime| {
        runtime.set_max_stack_size(1000);
        Ok(())
    }));
    
}
}

In the case of Lua, the runtime type is () i.e. This is because mlua does not have a separate runtime concept.

Accessing the World in Initializers

You can access the world in these initializers by using the thread local: ThreadWorldContainer:

#![allow(unused)]
fn main() {
use bevy::prelude::*;
use bevy_mod_scripting::prelude::*;
fn scripting_plugin(app: &mut App) {
    let plugin = LuaScriptingPlugin::default();
    plugin.add_context_initializer(|_context_key: &ContextKey, context: &mut Lua| {
        let world = ThreadWorldContainer.try_get_world().unwrap();
        world.with_resource::<MyResource>(|res| println!("My resource: {:?}", res));
        Ok(())
    });
    app.add_plugins(plugin);
}
}

Contexts

Each script runs in a context. By default BMS will create an individual context, or sandbox, for each script-entity pair that is run. This means that each script-entity pair will have its own set of global variables and functions that are isolated from other scripts. However, sometimes this might not be desirable. If you are not worried about scripts interfering with each other, or if you want to easily share data between scripts, you can consider using a different context policy.

Context Policies

Shared Context

A shared context means that all scripts run in the same context; there is in fact only one context to run in. If the scripts interact heavily with each other, this may be what you want.

To enable a shared context, set the corresponding context policy on the scripting plugin:

app.add_plugins(LuaScriptingPlugin::default().set_context_policy(
    ContextPolicy::shared(),
));```

## Per Script Context
A per script context provides each script with their own context. However, scripts may be attached to multiple entities, in which case a single script context is shared by multiple entities. 

To enable per script contexts, insert the `ContextPolicy::per_script()` resource.
```rust,ignore
app.add_plugins(LuaScriptingPlugin::default().set_context_policy(
    ContextPolicy::per_script(),
));```

## Per Entity Context
A per entity context provides each entity with their own context. The scripts attached to an entity via `ScriptComponent` all run in the same context.

To enable per entity contexts, insert the `ContextPolicy::per_entity()` resource.
```rust,ignore
app.add_plugins(LuaScriptingPlugin::default().set_context_policy(
    ContextPolicy::per_entity(),
));```

## Per Entity and Script Context
A per entity-and-script context provides each entity-script pair with their own context. This is a maximally isolated way to run scripts.

To enable per entity-and-script contexts, insert the `ContextPolicy::per_entity_and_script()` resource.
```rust,ignore
app.add_plugins(LuaScriptingPlugin::default().set_context_policy(
    ContextPolicy::per_entity_and_script(),
));

Custom Policies

Here is another way to write the per_script() policy.

let policy_a = ContextPolicy::per_script();
let policy_b = ContextPolicy { priorities: vec![ContextRule::Script, ContextRule::Shared] };
assert_eq!(policy_a, policy_b);

Reminding ourselves how ContextKey is defined,

pub struct ContextKey {
    pub entity: Option<Entity>,
    pub script: Option<Handle<ScriptAsset>>,
}

we read policy_b like this: if ContextKey has a script, return a ContextKey with only a script. Failing that ContextRule::Shared always returns an empty ContextKey.

One may also provide an entirely custom rule by implementing the ContextKeySelector trait.

Context Loading Settings

All context loading settings are stored in a separate resource per scripting plugin namely: ContextLoadingSettings<Plugin>.

The settings are as follows:

• loader - the load and unload strategy for contexts. Each scripting plugin will have a load and unload function which is hooked up through here
• context_initializers - stores all context initializers for the plugin
• context_pre_handling_initializers - stores all context pre-handling initializers for the plugin

More advanced applications might want to customize these settings to suit their needs.

Script Systems

It's possible within BMS to inject new systems from within scripts themselves.

Systems introduced by scripts can run in parallel to other systems, and can be freely inserted between any other system, including other script systems.

BMS also provides utilities for visualising schedules using dot graphs, allowing low-effort modding frameworks for game authors.

Schedules

Bevy doesn't support reflecting schedules, so BMS rolls it's own schedule registry resource: AppScheduleRegistry, which can be used to add any custom schedules you want to interact with. The default Bevy schedules will be pre-populated for you.

Once you've registered your schedule you will be able to interact with it in scripts like below:

local update_schedule = world.get_schedule_by_name("Update")
local systems = update:systems()
local system_with_name = update:get_system_by_name("my_system")

Inserting Systems

To insert a system you will need to use the system_builder global function like below:

local system = system_builder("my_system", script_id)
    :exclusive()
    :after(some_other_system)
    :before(another_system)

This will let you call world.add_system like so:

world.add_system(update_schedule,system)

Parameters

The system builder allows script authors to parameterise systems, using resource and query functions. The order in which those functions are called, will define the order in which arguments will be provided to the specified script callback.

For example:

system_builder("my_system")
    :query(
        world.query()
            :component(ComponentA)
            :component(ComponentB)
            :with(ComponentC)
            :without(ComponentD)
    )
    :resource(ResourceA)

will create a system which calls the specified callback my_system with 2 arguments:

• The ScriptQueryResult for the first query
  • With components access to ComponentA and ComponentB
• The ReflectReference to ResourceA

Exclusive systems

An exclusive system can be created using the exclusive function call on the system builder.

This allows the system to access everything as in a normal event handler.

Non-exclusive systems, will only be able to access the set of components and resources as parameterized when building the system. This is why we can run the system in parallel to other non-overlapping systems.

Exclusive systems on the other hand, cannot run in parallel.

Callback

The system injected will be similar to an event handler, however it will only trigger the specified script, and without any entity, in the first example you'd see the following lua callback:

function my_system()
    print("I am a dynamic system")
end

get triggered every update.

Examples

In the future we hope to embedd live WASM code examples into the documentation, for now the best source of example scripts will be our regression test suite available in all supported languages in our github repository.

For rust examples see this folder.

Release Notes

This section contains migration guides and release notes relevant to the bevy_mod_scripting crate.

This used to live in the repository, so for older release notes or guides, refer to the GitHub repository

Migration Guide: 0.13 to 0.14-alpha or 0.14 to 0.15

The most important changes to be aware of in this release are:

• BMS now uses Handle<ScriptAsset> as its principle means of referring to scripts as opposed to the ScriptId that was used previously.

• BMS exposes many more choices for deciding how scripts are associated with the contexts in which they run.

• script_id is replaced with script_asset which now has a type of Handle<ScriptAsset>.

Handles

The use of handles for scripts is perhaps the biggest user-facing change. It makes BMS asset usage follow Bevy's conventions. It requires less configuration. It is more idiomatic.

ScriptComponent Change

In prior versions, ScriptComponent accepted a vector of ScriptIds, which was a type alias for Cow<'static, str>.

-pub struct ScriptComponent(pub Vec<Cow<'static, str>>);
+pub struct ScriptComponent(pub Vec<Handle<ScriptAsset>>);

Because ScriptComponent accepts handles, it is no longer necessary to store the handles somewhere to prevent the script from unloading. Nor is it necessary to configure an asset path to script id mapper.

ScriptComponent(vec![asset_server.load("foo.lua")])

It is still beneficial to retain script assets in memory, for certain features to work. For example, script_asset will not be able to retrieve the asset path of the script if it's not retained.

ScriptId Change

The ScriptId has changed from being a string to being an asset ID.

-type ScriptId = Cow<'static, str>
+type ScriptId = AssetId<ScriptAsset>

No Evaluation on Load

In prior versions, BMS would immediately evaluate a ScriptAsset when it was loaded, and if multiple script assets were loaded, they would be evaluated in non-deterministic order. (See issue #426.) Script assets no longer evaluate immediately. Script assets are only evaluated when their handles are added to a ScriptComponent or they are added to StaticScripts.

In addition when a ScriptComponent loads its scripts, it loads them sequentially.

ScriptAssetSettings Removed

The ScriptAssetSettings has been removed. Let us address each of its fields in turn.

script_id_mapper

See AssetPathToScriptIdMapper section.

extension_to_language_map and supported_extensions

This is now represented by the LanguageExtensions resource, which can be configured directly during initialization

pub struct LanguageExtensions(HashMap<&'static str, Language>);

or by the ConfigureScriptAssetSettings trait:

app.add_supported_script_extensions(&["p8lua"], Language::Lua);

In addition one can configure the language of an asset when it is loaded:

asset_server.load_with_settings("hello.p8lua", |settings: &mut ScriptSettings| {
   settings.language = Some(Language::Lua);
});

or when it is created:

let content = String::from("x = 0");
let mut script = ScriptAsset::from(content);
script.language = Language::Lua;

ScriptMetadata and ScriptMetadataStore Removed

These were present to associate the previous ScriptId with the asset ID and language. That is no longer necessary as the ScriptAsset knows its own language.

pub struct ScriptAsset {
    /// The body of the script
    pub content: Box<[u8]>,
    /// The language of the script
    pub language: Language,
}

AssetPathToScriptIdMapper Removed

No mapper is necessary between a script and a script ID. If you have a script handle, you have its script ID

let handle: Handle<ScriptAsset> = ...;
let script_id: ScriptId = handle.id(); // ScriptId = AssetId<ScriptAsset>

and vice versa.

let script_id: ScriptId = ...;
let handle: Handle<ScriptAsset> = Handle::Weak(script_id);

Contexts

Choosing how scripts run is a big policy decision. Previously BMS had two options:

• Each script ran in its own context.
• All scripts ran in one context.

This was controlled by the enable_context_sharing() method on ConfigureScriptPlugin. That function is now deprecated. Instead use the set_context_policy method:

app.add_plugins(LuaScriptingPlugin::default().set_context_policy(
    ContextPolicy::shared(),
));

The reason for this change is there are many more choices than before, namely:

• ContextPolicy::shared()
• ContextPolicy::per_script()
• ContextPolicy::per_entity()
• ContextPolicy::per_entity_and_script()

See Contexts for more information.

ContextKey Added

Previously BMS used a ScriptId and sometimes an Entity to refer to a context. If there was no entity then Entity::from_raw(0) was used. Instead BMS now uses this ContextKey to look up contexts.

pub struct ContextKey {
    /// Entity if there is one.
    pub entity: Option<Entity>,
    /// Script ID if there is one.
    pub script_id: Option<Handle<ScriptAsset>>
}

This change affects the parameters for the context_pre_handling_initializers

- context_pre_handling_initializers: vec![|script_id, entity, context| {
+ context_pre_handling_initializers: vec![|context_key, context| {

and context_initializers:

- context_initializers: vec![|script_id, context| {
+ context_initializers: vec![|context_key, context| {

Recipients Changes

The Recipients enum now looks like this:

#[derive(Clone, Debug)]
pub enum Recipients {
    /// The event needs to be handled by all scripts, if multiple scripts share a context, the event will be sent once per script in the context.
    AllScripts,
    /// The event is to be handled by all unique contexts, i.e. if two scripts share the same context, the event will be sent only once per the context.
    AllContexts,
    /// The event is to be handled by a specific script-entity pair
    ScriptEntity(ScriptId, Entity),
    /// the event is to be handled by a specific static script
    StaticScript(ScriptId),
}

This aligns with how scripts are associated with contexts better.

ScriptCallbackEvent changes

The language for recipients is now controlled through the language field of the ScriptCallbackEvent. This allows for more flexibility in how callbacks are handled, especially when multiple languages are involved.

If no language is specified, the callback will apply to all languages.

#[derive(Clone, Event, Debug)]
#[non_exhaustive]
pub struct ScriptCallbackEvent {
    /// The label of the callback
    pub label: CallbackLabel,
    /// The recipients of the callback
    pub recipients: Recipients,
    /// The language of the callback, if unspecified will apply to all languages
+   pub language: Option<Language>
    /// The arguments to the callback
    pub args: Vec<ScriptValue>,
    /// Whether the callback should emit a response event
    pub trigger_response: bool,
}

Bindings Changes

ScriptId

script_id is replaced with script_asset which now has a type of Handle<ScriptAsset>. This means that you can no longer use a string to refer to a script, but rather you must use a handle.

Scripts can still access the asset path of the script using:

-- prints: "my_script.lua"
print(script_asset:asset_path())

ScriptAttachment

The concept of script attachments has been introduced to describe the idea of a script instance. Previously this was muddied due to the fact script ID's were the primary way to refer to scripts. Now the instance of a script and its mapping to a context is clearer.

This is reflected in a brand new set of bindings:

-- will create backing ScriptAttachment instances, that can be used in other bindings.
local entity_script = ScriptAttachment.new_entity_script(entity, script_asset)
local static_script = ScriptAttachment.new_static_script(script_asset)

System Builder

the system builder no longer accepts script id's as parameters. Instead it accepts script attachments

-system_builder("my_callback", "this_script_id.lua")
+system_builder("my_callback", ScriptAttachment.new_static_script(script_asset))

0.15.0 - Asset Handles and Context Policies

This release focuses on aligning bevy_mod_scripting with modern Bevy practices, most notably by switching to Handle<ScriptAsset> for script management. This change simplifies the API, removes boilerplate, and makes script handling more idiomatic.

Summary

Asset-First Workflow

Scripts are now treated as first-class Bevy assets. The old ScriptId (which was a string) has been replaced by AssetId<ScriptAsset>, and you'll primarily interact with scripts via Handle<ScriptAsset>.

// New way
let handle: Handle<ScriptAsset> = asset_server.load("my_script.lua");
commands.spawn(ScriptComponent(vec![handle]));

Scripts are now only evaluated when they are attached to a ScriptComponent or added to StaticScripts, which means you have more control over when and how scripts are executed.

Flexible Context Policies

You now have much finer control over how script contexts (i.e., the environment a script runs in) are created. The old enable_context_sharing() has been replaced with set_context_policy() which accepts a ContextPolicy:

• ContextPolicy::shared(): All scripts run in one global context
• ContextPolicy::per_script(): Each script asset gets its own context (the old default.)
• ContextPolicy::per_entity(): Each entity with scripts gets its own context.
• ContextPolicy::per_entity_and_script(): A unique context for every script on every entity (the new default).

This means that each script is maximally isolated by default, but you can still opt for shared contexts if needed.

Other Changes

• Recipients Enum: The Recipients enum for events has been redesigned to align with the new context policies, offering AllScripts and AllContexts variants, and removing some variants which don't fit the new model. If you need the old behaviour, you can simply query the ECS first before sending events.
• API Cleanup: Several types and traits were removed or simplified, including ScriptAssetSettings, AssetPathToScriptIdMapper, and ScriptMetadataStore, as they are no longer needed with the new asset-based approach.

Migration Guide

This release contains significant breaking changes. Please refer to the migration guide for detailed instructions on updating your project.

• Migration Guide: 0.14 to 0.15

Scripting Reference

This part of the book covers the user-facing API of the scripting languages supported by BMS. This will be where you will want to forward your script users to get started with scripting in BMS.

If you are a modder, welcome! 👋, apologies for the rust-centricity of this guide, we are working on it!

Globals

Scripts will have access to a few global variables in most callbacks:

• world: a static reference to the world, with all sorts of functions available
• entity: the entity the script is attached to, not available on load/unload callbacks, and in dynamic system callbacks.
• script_id: the ID of the current script

Constructing Arbitrary Types

When interfacing with bevy, we do this via reflection. While the generated bindings do not cover constructors for every single type that bevy or other libraries provide, reflection allows us to construct some (not all types implement FromReflect) types from dynamic structs.

BMS exposes this ability to all script writers via the construct global function.

Structs

The following struct:

pub struct MyStruct {
    pub my_field: String
}

can be constructed from lua like so:

local MyStruct = types.MyStruct
local concrete_my_struct = construct(MyStruct, {
    my_field = "hello"
})

Tuple Structs

The following tuple struct:

pub struct MyTupleStruct(pub String);

can be constructed like so:

local MyTupleStruct = types.MyTupleStruct
local concrete_my_tuple_struct = construct(MyTupleStruct, {
    _1 = "hello"
})

Enums

The following enum:

pub enum MyEnum {
    VariantA {
        field: String
    },
    VariantB
}

can be constructed like so:

local MyEnum = types.MyEnum
local variantA = construct(MyEnum, {
    variant = "VariantA",
    field = "hello"
})
local variantB = construct(MyEnum, {
    variant = "VariantB"
})

When working with enums you can also figure out the variant at runtime using variant_name:

if my_enum:variant_name() == "VariantA" then
    print(my_enum.field)
end

Core Bindings

Contents

This is an automatically generated file, you'll find links to the contents below

Globals

Global Values

Global values that are accessible anywhere inside scripts. You should avoid naming conflicts with these and trying to overwrite or edit them.

Instances

Instances containing actual accessible values.

Static Instances

Static type references, existing for the purpose of typed static function calls.

Functions

Non-Associated Functions

Global functions that are not associated with any type and callable from anywhere in the script.

For function details and documentation, click on the function link.

construct

Attempts to construct the given type, given an arbitrary map of values.

Arguments

Returns

system_builder

Creates a new script system builder, which can be used to add new systems to the world.

Arguments

Returns

Types

Available Types

All registered reflect-able types which can be constructed and directly manipulated by scripts.

World

Opaque Type. 🔒

Description

The ECS world containing all Components, Resources and Systems. Main point of interaction with a Bevy App.

Associated Functions

For function details and documentation, click on the function link.

exit

Quits the program.

Arguments

Returns

has_component

Checks if the given entity has the given component.

Arguments

Returns

remove_component

Removes the given component from the entity.

Arguments

Returns

register_new_component

Registers a new component type with the world.

The component will behave like any other native component for all intents and purposes. The type that will be instantiated to back this component will be DynamicComponent which contains just one field:

• data

This field can be set to any value and modified freely.

Arguments

Returns

push_children

Pushes the given children entities into the provided parent entity.

Arguments

Returns

get_resource

Retrieves the resource with the given registration.

Arguments

Returns

despawn_descendants

Despawn the descendants of the given entity.

Arguments

Returns

get_schedule_by_name

Retrieves the schedule with the given name, Also ensures the schedule is initialized before returning it.

Schedules in bevy are "containers" for systems, each schedule runs separately and contains different systems.

By default among others bevy contains the following schedules:

• Update: Runs every frame.
• PostUpdate: Runs after the Update schedule.
• FixedUpdate: Runs at a fixed rate.

Arguments

Returns

get_type_by_name

Returns either a ScriptComponentRegistration or ScriptResourceRegistration depending on the type of the type requested. If the type is neither returns a ScriptTypeRegistration.

Arguments

Returns

insert_children

Inserts the given children entities into the provided parent entity.

Arguments